From my point of view this is ready to go. Rational points in projective space will be a different issue.

P.S.: My Milnor-PR is behind yours, because I would like to also allow your rational points in the input.

Please close and reopen the PR to use the tests without the ones from duVal tests and FTheory tests affected by random error effects, which are currently being investigated.

After some discussion with @JHanselman we decided that point should have a parent point set.
To get a roughly consistent interface with the schemes, one may also view a rational point as a homomorphism.
But some of the point terminology is kept.

Rewrite with sets of rational points.

Let X be an affine / projective scheme. Should X([1,1]) return a rational point of X? Or a scheme point of X, i.e. a maximal ideal? I am not quite decided on this.

Let X be an affine / projective scheme. Should X([1,1]) return a rational point of X? Or a scheme point of X, i.e. a maximal ideal? I am not quite decided on this.

Mathematically it should return a scheme point of X (as X is a scheme). But I think in practice (and for computational purposes) it would be easier if it returned a rational point. I think that is also how Magma does it.

Let X be an affine / projective scheme. Should X([1,1]) return a rational point of X? Or a scheme point of X, i.e. a maximal ideal? I am not quite decided on this.

I need to e.g. to localize at a specified point or evaluate at it. @JHanselman on the other hand might have completely different operations in mind. So the 'right' choice will always be influenced by what the specific user expects. On the other hand, passage from one to the other should be available in any case and make this a minor question.

A more general remark:
Your change of viewpoint in commit 48336bc is a major change to the whole notion introduced in this PR.
Allow me to ask the standard question, which we always need to ask ourselves for design decisions in OSCAR: Which is the underlying textboot and what is closest to its spirit (mathematically/philosophically)?
In particular: are we in the scheme world or in the elliptic curve world and how are the two planned to interact?

I have been pondering your change of the meaing of parent and I need to express one doubt (for which I will be happy to hear an argument dispelling it):
Should parent be a simple getter without computing anything? In this case, the rational_point_set might pose some problem, because quite often you might know and want to use some rational point of a given scheme X, but not know the full rational point set of the (possibly higher dimensional) scheme X.
I agree with @simonbrandhorst and @JHanselman that it makes sense to see a rational point in the context of the rational point set. I am simply worried whether the way to access it should be a function as common as parent or some more specialized name.

The rational point set is basically an almost empty hull just like our rings, e.g. ZZ, or QQ[x], creating them does not compute anything. I mostly did it because magma and sage do it too.
In case one wants to iterate on the rational points points one can make
RationalPointSet iterable or add rational_points(::Scheme).

• A reason to have a rational point set is to have a unique parent-child relation.
• Another one is to allow P-points on a k-scheme X/k without having to compute the base changed scheme X/P.
• Rational points behave differently from closed points - closed points push forward; rational points pull back under base change.
• We could give the set of rational points E(k) of an elliptic curve E/k a group structure.

It would of course still be possible to work around all of this, by storing everything directly in the points/scheme.
I am not sure about the implications though and trusted on our competitors.

We are kind of in both worlds. Silverman in his arithmetic of elliptic curves, does it in coordinates and can hence avoid the language of schemes a k-rational point is a tuple of elements of k. Hartshorne defines them in a coordinate free fashion as a homset.

Your argument about the point_set being designed as an empty hull dispells my doubt. Thanks a lot !!!

I am aware of the difference between rational points and closed points under base change (one of the reasons why I am happy to have access to both).

The most important argument for the point_set for me is considering P-points of X/k without fully creating X/P.

Summing this up: This is green light for the changed perspective from me.

Concerning the differences in literature between Silverman and Hartshorne:

As we expect to have users from both worlds, we need to cater to their different needs anyway. We will probably end up with a few extra aliases for functions to allow people from the respective other world to intuitively find in their terminology, what they are looking for. (E.g. 'codomain' is far from intuitive for someone in the terminology of Silverman.) But we can leave this for a later PR.